<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
  <head>
    <title>GnuCash Project Goals</title>
    <meta name="description" content= "The Linux GnuCash project 
                aims at creating a world-class personal finance package. 
                Goals include ease-of use, double entry, OFX support, 
                charts, and reports, and multi-user support.">
    <meta name="keywords" content= "linux, OFX, accounting, finance, 
                financial, ledger, double entry, GPL, gnu">
  </head>

  <body bgcolor="#d6dacb" fgcolor="#000000">

    <div align=center><a href="https://www.gnucash.org/" target="_top">
    <img border=0 width=470 height=62 alt="GnuCash Personal Finance Manager"
     src="GnuCash_Long.jpg"></a><br>
    </div>

    <h1>GnuCash Project Goals</h1>

    <p>
    The people behind <a href="https://www.gnucash.org">GnuCash</a>
    aim to create a world-class GPL'ed Open Source Personal
    Financial Application for GNU/Linux and other Unix's. This page
    reviews some of the technical issues and development status
    surrounding this project. It is a kind of an <b>FAQ</b> for
    developers and contributors, providing status, and suggesting
    directions and technologies for deploying new features. If you
    simply want to get a better idea of what <a href=
    "https://www.gnucash.org">GnuCash</a> is and what it does, visit its
    <a href="https://www.gnucash.org">home page</a>. The home page
    contains screen shots, news items, and mailing list
    archives.
    </p>

    <p>
    There are currently several different versions of GnuCash.
    We've adopted the kernel numbering scheme: even minor release
    numbers (1.4.x, 1.6.x) are considered to mark stable releases,
    while odd numbers (1.5.x, 1.7.x) mark development releases.
    </p>

    <ul>
      <li>The current stable, production release is gnucash-1.6.0 and
          is based on the <a href= "https://www.gnome.org">Gnome</a> /
          <a href= "https://www.gtk.org">GTK</a> libraries.
      </li>

      <li>The 1.7.x releases focus on adding new features and
          improving existing functionality.
      </li>
    </ul>

    <p>
    The latest version is available only via CVS.  Occasionally,
    some of the more stable CVS versions are given a version number,
    and packaged as a precompiled deb or RPM install package. Naive or
    beginning users should probably stick to version gnucash-1.6.0.
    More adventurous users can try one of the 1.7.x releases, However,
    keep in mind that they are in a state of constant change and will
    often be unstable.
    </p>

    <p>This document is divided into several sections.</p>

    <ol>
      <li><a href="#arch">Architectural Goals</a></li>

      <li><a href="#reqs">Requirements</a></li>

      <li><a href="#size">Sizings</a></li>

      <li><a href="#feats">Features</a></li>
    </ol>
    <hr>
    <!--===================================================-->
    <a name="arch">
    <h1>Architectural Goals</h1>
    </a> 
    There are some over-reaching design principles and philosophies
    that we intend to maintain. Some of these concepts and terms
    are introduced in this section. 

    <h2>Separation of GUI and Data</h2>
    First, we must maintain a clean separation between the data
    structures and the GUI that manipulates them, along the lines
    of the <b>Model-View-Controller</b> paradigm. 

    <ul>
      <li>Lists of accounts and the transactions in them can be
          thought of as a representation of financial data, a 
          <b>Model</b>.
	  </li>

      <li>The GUI that adds, modifies and deletes these should be
          thought of as a manipulator of the data, a <b>Controller</b>.
          Thus, the Motif or Gnome GUI's are merely two possible
          manipulators of the data; others, based on <i>e.g.</i>
          web/cgi-bin, Qt/KDE, emacs, Java applets or Java servlets
          ought to be possible.</li>

      <li>The <b>View</b> of the data is a subset or slice of the
          data described by the Model. The View may consist of only the
          transactions for the month of May, or only the account totals
          for certain accounts. The View is used in part to generate
          the reports and graphs, but it is also that which the
          Controller interacts with. Views are generated by queries to
          the data store.</li>
    </ul>

    <p>
    GnuCash also needs to deal with multiple distributed data
    sources: stock quotations from the net or transaction
    confirmations from online banks and brokerage houses, or from
    more mundane sources, such as file imports, or merger of data
    from several users. Amongst these terms, the concept of a
    global Model-View is dated, and somewhat inappropriate. Rather,
    we need to be concerned about how data is represented in the
    local address space of the GUI, how the GUI manipulates it, how
    data is brought in and merged from external sources, and how
    that data is again output, whether to a file or a local or
    remote database.</p>

    <p>
    Thus, the <b>View</b> essentially represents a local data
    cache of the data that is immediately present and being
    displayed, reported, and manipulated. The <b>Model</b> is the
    abstraction of that data that the GUI (the controller) can act
    on.</p>

    <h2>The Financial Engine</h2>
    In GnuCash, the Model is implemented via the <b>Engine</b> API,
    and the View is the data that is currently in the <b>
    Engine</b>. Thus, the Engine is a set of programming API's that
    the GUI (or a script, or even a clever command-line-addict) can
    use to manipulate the data. 

    <p>
    Currently, the Engine provides basic accounting structures
    These include: </p>

    <ul>
      <li><b>Transactions</b>, which consist of a set of 'splits'
      or journal entries (JE's) whose values sum to zero.
      The transaction includes several date fields, a description,
      and a common-currency field, and a universal unique id 
      (uuid/guid).  It also provides hooks to store arbitrary data 
      associated with the transaction (using a URL-based key-value tree).
      </li>

      <li><b>Journal Entries</b> (internally referred to as
      'splits') which an amount and the account on which it is drawn.
      Splits also store reconcile status, dates, a memo field, 
      and also a key-value based hook for arbitrary data.
      </li>

      <li><b>Accounts</b>, which include a nme, a type, a description
      field, and the type of commodity they store.  Principlally,
      the account consists of a list of journal entries.</li>

      <li><b>Chart of Accounts</b>, which is a hierarchical tree of
      accounts.</li>
    </ul>

    The Engine has a basic two-phase commit model, and a 
    query mechanism for finding the data needed for reports and 
    views. The goal of the two-phase commit and query model is 
    allow the creation of multi-user server based backends, such
    as an SQL backend, and RPC client-server backend, or an 
    XML-based HTTP/web backend.  This design seems to work 
    for the above-named backends.
    
    <p>The Engine currently handles only a basic set of data
    sources:</p>

    <ul>
      <li>It can import and merge in QIF's (actually, this function
          has been moved into the GUI, and is no longer part of the 
	  engine);
	  </li>

      <li>It can read and write its own XML byte stream;
          This ability has been used to provide a multi-user
	  client-server demo (which is currently broken).
          </li>

      <li>It can use a Postgres SQL database as a datastore, thereby
          enabling multi-user and auditing functions.
	  </li>

      <li>It can talk, via RPC, to a gnucash server.  (This code is 
          'alpha' and incomplete/broken).
	  </li>
	  
      <li>It can get stock quotes from the net (actually, this 
          function is provided by a separate module, the Finance::Quote
	  perl module.)
	  </li>
    </ul>

    <p>
    However, since the Engine is meant to be the interface
    between the GUI and the financial data, it is really intended
    to be able to do much more.
    In particular, it should be possible to create a peer-to-peer
    network model, where gnucash peers can synchronize data between
    themselves.  The engine should also be expandable to handle other 
    sources of data, such as OFX/IFX, the Open Trading Protocol, or 
    the OMG CORBA General Ledger submission.  In particular, it
    should be possible to use GnuCash not only to view data from
    these sources, but also to manipulate it and send it back.
    </p>

    <h2>Modularity, Extensibility and Customization</h2>

    <p>The above structure should lead us to view GnuCash not so
    much as a tightly integrated application, but rather as a loose
    confederation of component objects, libraries and interfaces.
    This has a number of advantages for both the deeloper and the 
    user.  For the developer, it allows parts to evolve semi-independently
    of one-another, and to be used in other, non-gnucash projects.
    For the user, a good extensibility allows the use of
    <a href="#arrangements">arrangements</a>: a way of broadly
    customizing the appearance and behaviour of gnucash, and then 
    allowing users to very easily share these customizations with 
    one another.  Such arrangements might be collections of canned 
    reports, e.g. for business or home user.  Or they might be
    the menu contents: one menu arrangement is for gbeginners, another 
    for 'power users', a third for business owners.  Th goal is that
    broad areas should be not only customizable, but it should be
    possible, even easy, to trade these customizations between users.
    </p>
    <p>
    In order to facilitate the gluing together of these parts, as
    well as simplify the questions of customizability, change and
    rapid development, GnuCash makes use of the 
    <a href= "https://www.swiss.ai.mit.edu/projects/scheme/index.html">
    Scheme</a> extension language (as implemented in the FSF 
    <a href="https://www.gnu.org/software/guile/guile.html">Guile</a>
    interpreter), to glue the pieces together. (Note that the
    engine interface is also available with 
    <a href="https://www.perl.org">Perl</a> interfaces, thanks to a
    <a href="http://starship.skyport.net/crew/beazley/swig.html">SWIG</a>
    wrapper.
    </p>

    <h2>A Web Browser for Financial Data</h2>

    <p>More and more financial data is moving onto the web.  
    People shop on-line. They pay bills on-line.  There are
    even some promising e-wallet systems (such as 
    <a href="https://www.webfunds.org">WebFunds</a>).  For GnuCash
    to be relevant in this on-line world, it must be able to interact
    with these systems.  There are several steps that can be taken
    along this path.  First, it must be possible to simply and
    transparently import financial data off the web.   Click on a QIF
    file, mime-type "application/x-qif"? Gnucash sucks it in without 
    burping.  But, in a more distant future, can GnuCash originate
    transactions? It should be able to!  
    </p>
    <p>
    GnuCash can be and should be "The Sophisticated Financial Web Browser".
    All GnuCash reports and the help system are HTML-based.  In fact,
    GnuCash has a built-in web browser that can view ordinary web sites.
    Interactive gnucash components such as the bar and pie charts, or
    the graphs and reports, can all be served up by a remote web server,
    as well as locally through the GnuCash application.  This allows
    GnuCash to blur the line between web browser and financial application,
    and offer the best of both worlds.
    </p>
    <p>
    Why is this a good thing?  One can always have a pure web-based
    accounting solution (such as SQL-Ledger) that uses ordinary web
    browsers to view the financial data. But there are problems:
    dynamically-generated html and cgi-bins aren't as pretty or easy 
    to use, or as fast, responsive or sophisticated, as what you can 
    do with a custom client.   That is, GnuCash can be more interactive,
    easier to user, slicker and more professional looking in style 
    and presentation than a plain-old dynamic website.  Financial
    ASP's simply cannot currently offer the kind of utility, flexibility,
    responsiveness and integration that GnuCash can offer.
    </p>
    <p>
    In theory, the 'Java revolution' was supposed to provide this 
    function, with downloadable Java applets providing the 'fancier-
    than-plain-html' interface.  But a Java applet that is this 
    sophisticated would also be large and slow to download:
    it offers no inherent advantages over native code.  Another 
    problem with Java is the inherent propreitary fragmentation: 
    no two Java applets are alike: every site has their own; there
    is no standardization. 
    </p>
    <p>
    In order to solve the 'no gui standardization between websites'
    problem, there are a number of businesses that have arisen to 
    provide "financial aggregation".  You sign up with these sites,
    and let them get all of your credit-card, bank and investment info,
    and they can provide a unified interface for your bank statements,
    with graphs and reports (all for a monthly fee).  The existence of
    these services highlights a problem: the inability to aggregate
    the same data on the users desktop, in a simple, coherent fashion.
    Let us posit that GnuCash, with the right on-line interfaces, 
    would be a natural for this.  For the paranoid,
    this has the added advantage that no one business has access to
    all of your financial records.
    </p>

    <p>
    To put it another way, GnuCash can provide a centralized, trusted 
    store for financial data that no other application can provide.  
    The convenience 
    factor:  if you have trading accounts at e*trade and charles schwab,
    then GnuCash can be the central place where you can oversee 
    <b>all</b> of your investments.  The trust factor:  
    maybe you can trust your web bank. Maybe you can trust your web 
    stock account.  But can you trust a single web entity with *all*
    of your financial data?  Someone who won't treat you as 'just 
    another consumer' and sell your 'consumer profile' to anyone who
    cares to stalk (ahem, target) your financial activity (ahem,
    purchasing) patterns?  Didn't think so.   Of course, you
    *could* use some proprietary financial software.  Assuming, of course,
    that you trust it not to have any built-in covert channels:
    nothing that might send back the make and model of your CPU and 
    the last ten transactions 'home to mommy' for 'diagnostic purposes'.
    Because open source software, such as GnuCash, can be audited
    it can be trusted in ways that no proprietary software can be.
    In an increasingly net-connected world, the ability to build 
    trust through audits will be increasingly important.
    </p>

    <h2>Looking Into the Future</h2>
    Things like support for OFX, and small-business features are
    hopefully in the near term future of gnucash.  Lets take a look
    at some more far-out possibilities.
    </p>
    <dl>
    <dt><b>E-Wallet</b></dt>
    <dd>An e-wallet, just like a real wallet, stores cash.  You
        can use that cash to pay friends or businesses.  Just
	like a real wallet, an e-wallet should not charge you 
	monthly fees.  It should provide you with some measure
	of anonymity and privacy.  An e-wallet should also do 
	something no ordinary wallet can do: show you a monthly
	report of expenditures.  GnuCash should get e-wallet 
	features. </dd>

   <dt><b>Authentication, Authorization and Access Control</b></dt>
   <dd>How does an on-line merchant know that you are who you say
       you are?  How can you use GnuCash to authorize a bill payment?
       Sooner or later, smart-cards will provide the sort of 
       authentication and access control that is only groped for 
       with PGP/GPG, keyrings, x.509 certificates, and Microsoft 
       Passport/Hailstorm.   Of all the electronic things in the
       electronic world where access control and authentication
       are important, real money is the most so.  
       </dd>

    <dt><b>Bill Presentment, Bill Pay</b></dt>
    <dd>These magic keywords just mean that a merchant wants to 
        send you a bill, and wants you to go to their website to
	pay that bill (they want your eyeballs).  Of course, for
	the user, it would be more convenient to have the bill
	show up on the desktop, inside of gnucash, and get authenticated
	and paid out from the desktop (by gnucash), as you would
	do with all of your other bills.
    </dl>

    <hr>
    <!--===================================================-->

    <a name="reqs">
    <h1>Requirements</h1>
    </a>
    Lets take a look at who the current and potential future users
    of GnuCash are, and how they might use it.   The classes:

    <ul>
      <li>Basic Household Accounting/Budgeting</li>
      <li>Personal Stock Portfolio Management</li>
      <li>Personal On-line Trading (Day-Trading)</li>
      <li>On-line shopping and bill-pay</li>
      <li>Small Business Users</li>
    </ul>
    These different applications may use some of the same 
    financial terminology, and hopefully might share a fair 
    bit of code, but have quite different goals and requirements. 

    <h3>Basic Household Accounting and Budgeting</h3>

    <p>Important properties of a personal finance system
    include:</p>

    <ul>
      <li>Approachable and usable by occasional users
          who are not knowledgeable about accounting.</li>

      <li>Ease of use and simplicity is critical.</li>

      <li>A reasonable selection of reports, graphs, charts, and
          tools for personal finance, such as mortgage
          calculations.</li>

      <li>Budgeting support needs to be targeted at <em>naive</em>
          users.</li>

      <li>Interfaces to on-line banking, shopping, stock
          systems.  Bank and credit-card statements should
          arrive 'automatically' and always be up-to-date.</li>
    </ul>
    
    <h3>Personal Portfolio Management</h3>

    <ul>
      <li>Support for management of stock portfolios that may
          involve considerable sophistication, since individuals
          commonly have retirement plans that hold mutual funds,
          stocks, options, bonds, and the like.</li>
      <li>Reporting infrastructure needs to simplify handling of
          tax issues (long-term vs. short-term capital gains/losses,
	  cost-basis FIFO accounting, simplfied cost-basis 
	  spinoff/merger handling).  Need on-line updates of
	  prices, simple portfolio overview, ability to link
	  to websites for additional research.
      <li>Integration with on-line trading systems.  This could 
          save time typing.
      <li>Basic Audit features.  There's a problem with blindly
          allowing on-line data (prices, transactions) to enter
	  GnuCash.  It may not be clear where it came from,
	  and even if the source is believed to be 'reputable',
	  there still may be factual errors in the data.  Thus,
	  there must be a way of audting newly-arrived (or even old)
	  on-line data, and mark it as 'reconciled', i.e. 
	  manually reviewed and checked for accuracy.  That is,
	  incoming on-line data must be auditable, and audit
	  trails should mark the history of on-line data import.
    </ul>

    <h3>Small Business Needs</h3>

    <ul>
      <li>With a business system, it is likely that there will be
          users who use it eight hours a day, which puts the emphasis 
	  on <em>efficiency</em> of user interface rather than on its
          approachability to naive users.</li>

      <li>Business systems require network support, and the ability
          to support multiple simultaneous users.</li>

      <li>Some business users may want access to the system from an
          MS Windows 95/98/NT box. For these folks, a web-based
          interface could be just handy. Web interfaces are also nice
          a for ASP type deployment.</li>

      <li>
        Small businesses do not often have sophisticated investment
        portfolios; they instead need support for additional
        sophistication in such areas as: 

        <ul>
	  <li>Customer and Vendor Lists; Invoicing</li>
	  
          <li>Payroll (Batch processed and individual)</li>

          <li>Inventory Control &amp; Asset Management</li>
          <li>Amortization Schedules, Depreciation</li>

          <li>Shipping and Receiving</li>

          <li>Accounts Receivable, Accounts Payable (A/R, A/P)</li>
          <li>Credit Card Processing</li>

        </ul>
      </li>

      <li>Support for calculations associated with accrual
          accounting.</li>

      <li>Ambitions for the future might include interfaces to
          online shopping carts, credit card clearing interfaces, and
          ERP systems.</li>
    </ul>

    <h3>Reconciling Those Needs</h3>

    <p>A seemingly contradictory factor is that the kinds of
    sophistication that are required vary considerably.
    Consider:</p>

    <ul>
      <li>A home user does not generally require most of the
      sophistication of accrual accounting that is
      required by business enterprises. Thus, home users don't need
      <em>much</em> of the sophistication of an Accounts Receivable
      or Payable system, or the <em>bizarre</em> depreciation
      policies that crop up in Asset Management systems.<br>
      <br>
      </li>

      <li>
        On the other hand, home users are in increasing need of
        surprisingly sophisticated financial tools for managing
        stock portfolios, including: 

        <ul>
          <li>Mutual funds</li>

          <li>Retirement savings plans, with such identifiers as
          401(k), IRA, Roth IRA, RRSP, or Insurance Annuities</li>

          <li>Corporate stock purchase plans</li>

          <li>Corporate option plans</li>
        </ul>
      </li>
    </ul>
    Another set of contradictory requirements has to do with the
    back-end, and interfacing to other systems: 

    <ul>
      <li>Home users need a simple-to-install, simple-to-maintain
      system. This essentially rules out the use of SQL for the
      storage medium/back-end for home users. (That is, the current
      state of the art for SQL on Linux does not offer any simple,
      fool-proof management for data).</li>

      <li>By contrast, non-SQL systems for business use are almost
      unimaginable. SQL provides a high degree of data integrity
      and storage robustness, and also simplifies tremendously the
      import and export of data. Powerful SQL tools exist that can
      work magic in the hands of a good DB admin.</li>
    </ul>

    <p>It may be that these will require <em>completely</em>
    different systems, and that GnuCash cannot be "all things to
    all people." This remains to be seen.</p>
    <hr>
    <!--===================================================-->

    <a name="size">
    <h1>Sizings</h1>
    </a>
    This section attempts to guess how hard it would be to
    implement certain features. 

    <h2>Personal Financial Application</h2>
    Below are listed the technical work items needed to implement
    the features that home users might hope to have. They are
    listed in approximate order of priority. 

    <p>The right hand column shows a sizing guesstimate. pm ==
    person-months. These sizings are meant to show 'effort needed
    to complete', rather than 'total effort required'. Thus,
    half-finished items have smaller sizings.</p>

    <ul>
      <li><b>Done</b> The work item is essentially completed</li>
      <li><b>Small</b> 0 to 4 pm</li>

      <li><b>Medium</b> 3 to 12 pm</li>

      <li><b>Large</b> More than 12 pm</li>
    </ul>

    <table border="1" summary= "Personal Finance Functionality Requirements">
      <tr>
        <th>Feature</th>
        <th>Sizing</th>
        <th>Responsible</th>
      </tr>

      <tr>
        <td></td>
      </tr>

      <tr>
        <td><a href="#i18n">Internationalization</a></td>

        <td>Done</td>
        <td>-</td>
      </tr>

      <tr>
        <td><a href="#reports">Reports</a></td>

        <td>Medium</td>
        <td>Stimming/Gribble</td>
      </tr>

      <tr>
        <td><a href="#graphs">Graphs</a></td>

        <td>Medium</td>
        <td>Guppi/Gribble</td>
      </tr>

      <tr>
        <td><a href="#query">Transaction Query</a></td>

        <td>Small</td>
        <td>Linas/LewisMoss</td>
      </tr>

      <tr>
        <td><a href="#ledger">Simplified Ledger</a></td>

        <td>Done</td>
        <td>-</td>
      </tr>

      <tr>
        <td><a href="#glitz">Themes, Icons, Glitz</a></td>

        <td>Small</td>
        <td>Various</td>
      </tr>

      <tr>
        <td><a href="#misc">Miscellaneous Small Tasks</a></td>

        <td>Done</td>
        <td>Various</td>
      </tr>

      <tr>
        <td><a href="#alerts">Alerts, Recurring & Scheduled Transactions</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#budget">Budgeting</a></td>

        <td>Medium</td>
        <td>Dave</td>
      </tr>

      <tr>
        <td><a href="#classes">Classes/'Action' Field</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#book">Books, Accounting Periods</a></td>

        <td>Small</td>
        <td>Linas</td>
      </tr>

      <tr>
        <td><a href="#check">Check Printing</a></td>

        <td>Small</td>
        <td>Grib</td>
      </tr>

      <tr>
        <td><a href="#wizards">Wizards</a></td>

        <td>Small</td>
        <td>Dave, Bill-qif</td>
      </tr>

      <tr>
        <td><a href="#arrangements">Arrangements</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#userpref">User Preferences/Session Mgmt.</a></td>

        <td>Done</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#quickim">Quicken(TM) QIF Import</a></td>

        <td>Small</td>
        <td>Gribble</td>
      </tr>

      <tr>
        <td><a href="#iifim">IIF Import</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#quickex">IIF Export</a></td>

        <td>Small</td>
        <td>Grib</td>
      </tr>

      <tr>
        <td><a href="#currency">Multiple Currencies</a></td>

        <td>Medium</td>
        <td>Rethink Requirements-Linas</td>
      </tr>

      <tr>
        <td><a href="#architecture">Architecture Review</a></td>

        <td>Small</td>
        <td>RLB, Dave</td>
      </tr>

      <tr>
        <td><a href="#testing">Automated Test Suite</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#quote">Stock Quotes, Price Quotes</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#install">Install</a></td>

        <td>Small ?</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#double">Forced Double Entry</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#401K">401K etc.</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#searchdocs">Searchable Documentation</a></td>

        <td>Done</td>
        <td>grib</td>
      </tr>

      <tr>
        <td><a href="#reconcile">Reconcile Auditing</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#note">Annotate with Investment News</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#loan">Loan and Mortgage Calculators</a></td>

        <td>Small</td>
        <td>Dave</td>
      </tr>

      <tr>
        <td><a href="#overdraft">Overdraft Alerts</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#tech">Technical Stock Analysis</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#sink">Depreciation, Sinking Funds</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#ofx">OFX, Online Banking, Trading,
        Bill-pay</a></td>

        <td>Large</td>
        <td>Dave</td>
      </tr>

      <tr>
        <td><a href="#tab">Tab-delimited ASCII export</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#tax">Tax Preparation</a></td>

        <td>Large</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#palm">Sync with Palm Pilot
        organizers</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#emerg">Emergency Records Organizer</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>
    </table>

    <h2>Small Business Features</h2>
    Features that small/medium businesses expect. 

    <table border="1" summary=
    "Business Functionality Requirements">
      <tr>
        <th>Feature</th>

        <th>Sizing</th>
        <th>Responsible</th>
      </tr>

      <tr>
        <td>
        </td>
      </tr>

      <tr>
        <td><a href="#engine">Enriched Engine, Financial
        Objects</a></td>

        <td>Large</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#sql">SQL I/O</a></td>

        <td>Done</td>
        <td>Linas</td>
      </tr>

      <tr>
        <td><a href="#multiuser">Multi-User Support</a></td>

        <td>Small</td>
        <td>Linas</td>
      </tr>

      <tr>
        <td><a href="#addressbook">Address Book</a></td>

        <td>Small</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#arap">A/R, A/P Accounts Payable,
        Receivable</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#payroll">Payroll</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#invoice">Invoicing</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#estimate">Job Costing</a></td>

        <td>Medium</td>
        <td>?</td>
      </tr>

      <tr>
        <td><a href="#expense">Expense Accounts</a></td>

        <td>Large</td>
        <td>?</td>
      </tr>
    </table>
    <hr>
    <!--===================================================-->

    <a name="feats">
    <h1>Features and Functions</h1>
    </a>
    This section reviews the current status of various features.
    Some of these are 'in process', some are 'almost done', some
    are 'completely done'. This section thus provides status on
    both where we've been, and where we're going. 

    <dl>

      <dt><a name="i18n"><b>Internationalization</b></a></dt>

      <dd>
        All menus, markup and help-text should be
        internationalized, so that GnuCash may be usable in any
        country. This would include the printing of currency values
        in the local country conventions. 

        <p><b>Current status:</b>
        Essentially Done (?)
        <ul>
          <li>All GUI messages currently use GNU <tt>gettext()</tt>
          for the message catalogs. Translations exist for English,
          British, French, Swedish, German, Japanese.</li>

          <li>Help pages available only in English and French.</li>

          <li>Monetary and string handling done through glibc. The
          latest glibc (2.2.3) is needed to get the correct
          functions.</li>

          <li>Yannick Le Ny &lt;y-le-ny@ifrance.com&gt; traduction
          en francais</li>

          <li>Most GUI input elements use the gtk text widget, and
          thus use the XIM input method in Asian locales. This
          allows <i>e.g.</i> Kanji, Katakana support. However, the
          register does <em>not</em> use XIM, and thus doesn't
          currently support the Asian languages. This needs
          fixing. (This may be done already??)</li>
        </ul>
        </p>
      </dd>

      <dt><a name="reports"><b>Reports</b></a></dt>

      <dd>
        A variety of reports, including Net Worth, Balance Sheets,
        and Profit and Loss statements. These should be printable:
        that is, exportable as HTML as well as print-ready
        postscript. These should be easy to customize. Ideally,
        even novice users should be able to create custom reports. 

        <p>The Report Generator should be a separate but "dockable"
        subsystem of the whole. That is, it should be possible to
        run the report generator in a stand-alone, read-only
        fashion without having to start up the main application. It
        should be possible to run reports nightly from a
        command-line and/or cron job.
	The GUI should remember what reports were run last time, and
	these should be re-run/redisplayed whenever the report generator
	is used.
	</p>

        <p>One difficult aspect of reporting is designing a
        configurable interface, so that people can build custom
        reports. The <a href="xacc-reports.html#NEWREP">New
        Reporting Infrastructure</a> is seeking to build this up
        using Guile.   Note there are several flavours of customization:
        <ul>
        <li>Allow user to specify a custom logo (e.g. company 
	    logo/address) on every page
            (generically, having a header and footer for every page).
        <li>Allowing user to modify report title/subtitle on the fly
            (and possibly add notes at the top or bottom of the report,
            e.g. to explain line items).
        <li>Allow user to use the <a href="#query">transaction query</a>
            interface to pick the set of transactions that will make up
            the report.
        <li>Memorize the report that was asked for, give that report
            a name, and in the future, allow that same exact report 
            to be re-run.  Allow user to edit this report properties
            at a later date.  Note that the basic idea is similar to 
            that of <a href="#query">memorized queries, discussed below.</a>
        </ul>
        Note that the customization info should be stored in a 
        <a href="#arrangements">Arrangements File (see below)</a>.
        </p>

        <p>Generated reports should be exportable to other gnome
        systems (probably using bonobo). 
        Reports should also be exportable to
        the Gnumeric spreadsheet (probably by writing out gnumeric
        file format).  Export of CSV (comma separated values) and
	tab-delimited formats (for other spreadsheet import) would
	be good.  Tables & etc. should be exportable to AbiWord,
        StarOffice, other word processors. (formats: docbook sgml?
        would then make convert to richtext, TeX easy.)
	Export should be as wysiwyg as possible.
        </p>

        <p>Must be possible to e-mail reports (for example,
	invoices) to users.  Suggest an evolution addressbok
	/mailer bonobo plugin.
        </p>

        <p>
        Relationship to budgeting not clear ... 
        </p>

        <p>Stock portfolio tools should include a Cost Averaging
        report, Market Index report, Stock Option values,
        Estimation of capital gains tax liabilities.</p>

        <p>Reports should be printable to printer (postscript/
	Adobe Acrobat). 

        <p>
        <b>Status:</b>

        <ul>
          <li>A general reporting infrastructure was implemented in
              Perl, in the form of html-embedded perl (ePerl). However,
              this reporting mechanism was abandoned in part because
              ongoing build and install problems related to ePerl and
              swig. Also, since ePerl didn't participate in the
              interpreter even loop, the report generator had to run
              as a separate process, reading data via pipes. This was
              uglier than some folks liked.</li>

          <li>A general reporting infrastructure has been <a href=
              "xacc-reports.html#NEWREP">implemented in Scheme</a>.
              Currently, there are a variety of reports for Profit/Loss,
              Balance Sheet, and portfolio valuation; none are 
	      particularly sophisticated.</li>

          <li>Done: Reports are displayed with the gtk-html widget.
	      This widget provides postscript printing and Acrobat 
	      output.
              </li>

          <li>There is currently no way (no longer any way??) to
              generate reports from the command line ...</li>

          <li>While many reports have been implemented, there is
	      no master list of what we should have.  We should have ....
          </li>

          <li>The following technologies were rejected/unused mostly
              because they were too complex, didn't hang together technologies:
              <a href= "http://www.oasis-open.org/cover/">SGML</a> and <a href=
              "http://www.oasis-open.org/cover/xml.html">Extensible
              Markup Language - XML.</a> In the long run, these are
              preferable to HTML, since <a href=
              "http://www.jclark.com/dsssl/">DSSSL</a> tools such as <a
              href="http://www.jclark.com/jade/">Jade (James DSSSL
              Engine)</a> can be used to convert to RTF, Postscript, etc.
              Add to this the consideration that XML is the basis for the
              <a href="https://www.w3.org/DOM/">Document Object Model</a>,
              which is being integrated into many web-based applications,
              and we can see that XML is an increasingly significant
              format as we look to the future.
        </li>

        </ul>
        </p>
      </dd>

      <dt><a name="graphs"><b>Graphs</b></a></dt>

      <dd>
        <p>Provide support for graphs, charts, etc., such as:
           Asset allocation pie chart, portfolio value vs. cost,
           ROI.  Graphs should be printable to printer.
           Graph generation should be fully integrated with reporting,
           both for data collection via queries, and for displayed
           output.
        </p>
        <p>
        <b>Status:</b>
        <ul>
          <li>Different graphing packages were evaluated, 
              <a href="https://www.gnome.org/guppi/">GUPPI</a>.
              Guppi was chosen.  Considered & rejected were
              plotutils, gnumeric graphing code (Miguel says 
              they'll replace gnumeric code with guppi.)
              Miguel's/Gnumeric requirements were:
              interactive plot editing -- each segment attributes 
              totally settable/controllable -- drag/move callbacks 
              when segments are click-dragged.
          </li>
	  <li>Basic pie charts and bar charts are used in GnuCash
	      reports.  There are problems: dates along the bottom
	      of a bar-chart are not well-spaced/autoscaled. 
	      The over look is a bit klunky.
        </ul>
        </p>
      </dd>

      <dt><a name="query"><b>Transaction Query</b></a></dt>

      <dd>
        Allow user to build (complex) queries to locate a 
        set of transactions that match some criteria: e.g.
        a date range, or a matching payee, description, amount,
        etc.  Once a user has created a complex query, it
        must be possible to memorize it (i.e. give it a name,
        and store it for future reuse).

        <p>
        <b>Status:</b></p>
        <ul>
          <li>The query engine has been implemented (as of 1.4.0,
              grib)
          </li>
          <li>The GUI for creating queries has been implemented
              (as of 1.4.0, grib)
          </li>
          <li>The queries are handled by the Postgres SQL backend.
	      (as of 1.6.0, linas)
          </li>
	  <li>Queries can be turned into XML and back, for file 
	      storage or network transmission.  This used to work
	      for XML version 1 but was broken in version 2.
          </li>
          <li>The ability to memorize queries has <b>not</b>
              been implemented and awaits further action (needed
	      for reports, above).
          </li>
        </ul>
      </dd>

      <dt><a name="ledger"><b>Simplified Ledger</b></a></dt>

      <dd>
        Ledger should look clean, work easily.

        <p>
        <b>Status:</b></p>
	Essentially done.
        <ul>
	   <li>Multi-line ledger confusion fixed by using correct 
	       left-right journal display style.
	       Fixed in 1.6.0, Peticolas, Champaigne.
	   </li>
	   <li>
               Stocks and Mutual funds are handled by placing them each in
               their own account. Each account can be viewed individually.
               If all of the stock accounts are children of a master
               trading account, then the trading account can be viewed and
               modified in a General Ledger window. 
	       Layout problems fixed in 1.6.0.
	   </li>
	   <li>
              How to most simply allow the user to enter loads and fees?
              Through multi-line transactions. Seems to work well in
	      1.6.0.
	   </li>
        </ul>
      </dd>

      <dt><a name="glitz"><b>Themes, Icons, Glitz</b></a></dt>

      <dd>
        A variety of finer touches need work: 

        <ul>
          <li>
            <p><b>Hint-of-the-Day</b>. A collection of a some
            50-100 hints-of-the-day: short (2-4 sentence)
            hints/tips on how to use gnucash. Every time the user
            starts gnucash, an new hint shows up ...
            <b>Status:</b> Hint infrastructure complete (RGMerkel, 
	    version 1.4.0).  Need to add
            hints  (only a dozen are currently available).
            </p>
          </li>

          <li>
            <p><b>Themes</b>. Some theme testing required. The
            effect of themes on the register window needs to be
            reviewed.  Some themes look flaky in the main account
            window, might be a gtk bug ???</p>
          </li>


          <li>
            <p><b>Household Assets/House Inventory</b> 
            Add wizard to walk user through a set of questions
            about household inventory & help user value them.
            (do you own a house? appraised value? mortgage?
            do you own jewelry? appraised value? etc.)
            In particular, show how appreciation
            and depreciation should be treated.
            See the section <a href="#arrangements">Arrangements</a> for
            a discussion of the customization issues.
            </p>
          </li>

          <li>
            <p><b>More account types</b> Introduce more
            'fundamental' account types: (amortized) Loan,
            Mortgage, ESOP, House, Line of Credit.</p>
          </li>

          <li>
            <p><b>Register View</b> Allow user to view only
            non-reconciled transactions ...</p>
          </li>

          <li>
            <p><b>Configurable main-window Status Bar</b> Bottom of
            main window currently shows total asset, and total
            income-expense (profits). Make this configurable, so
            that user can show arbitrary sums of arbitrary
            accounts.
	    This is mostly solved by having the MDI interface 
	    have reports, and the use of multi-paning.  But the
	    default display for gnucash should be changed to 
	    show a very small (1-4 line) networth and P&L report,
	    and maybe a cash-flow report.
            See the section <a href="#arrangements">Arrangements</a> for
            a discussion of the customization issues.
            </p>
          </li>

          <li>
            <p><b>Dockable Registers/ aka "Browser Mode"</b>.
            Currently, when each new register opens, it opens in a
            new window. An alternate style would be to 'dock' the
            register window in a bigger frame, and just have
            'backward/forward' buttons to navigate through
            different registers (the way that a browser navigates
            web pages.) This of course would be a user
            preference.  Possibility for doing this exists with MDI.
	    Maybe we shouldn't bother doing this ?? </p>
          </li>

          <li>
            <p><b>Context sensitive help</b>. When users
            create new accounts, need to suggest stuff if the user
            typed something unexpected ... (<em>e.g.</em>
            non-alphanumeric input) ...</p>
          </li>

          <li>
            <p><b>Folder Tabs</b> Currently, Income/Expense
            accounts can be shown or hidden by selecting from a
            menu. It would be nice to be able to examine different
            account types (Asset, Liability, Income, Expense,
            Payables, Receivables, Inventory) by selecting a tab
            folder. This is maybe a bs. request that shouldn't 
	    be implemented.</p>
          </li>

        </ul>

      The following have been completed, but possibly not fully
      documented:
        <ul>
          <li>
            <p><b>Pop-up Calendar</b> All date fields should pop up
            a calendar widget; selected date should get entered in
            field. (peticolas, version 1.4 ??)</p>
          </li>

          <li>
            <p><b>Pop-up Calculator</b> All price/amount fields
            should pop up a calculator widget; output of calculator
            gets entered in field. Instead of a popup calculator,
	    this was implemented by allowing all fields to take 
	    algebraic expressions (plus, minus, times, divide).
	    (rlb ?? version 1.6.0)
	    </p>
          </li>

          <li>
            <p><b>Button Bar</b> A user-configurable button-bar.
	    Solved in version 1.6.0 with tabs, not buttons, via
	    gnome MDI (gribble, version 1.6.0)
            See also the section <a href="#arrangements">Arrangements</a> 
	    for a discussion of the customization issues.
            </p>
          </li>
          <li>
            <p><b>Currency Exchange Table</b> 
            Keep a currency exchange-rate table.  This is now 
	    automatically handled via the 'price database'
	    (rlbrowning, version 1.6.0)
            (the finance::quote perl module handles currency 
	    exchange rate fetches)
            </p>
          </li>

          <li>
            <p><b>Currency Selection Pop-up</b> Currency field
            should get replaced by menu of long-hand currency
            names, three-letter ISO 4217 abbreviations, and symbols.
            User should be able to hand-enter non-IS4217 currencies.
            <b>Status:</b>
            Done in 1.4.0
            </p>
            </p>
          </li>

          <li>
            <p><b>Cut-n-paste</b> Cut-n-paste of whole transactions
            in the register window... <b>Status:</b> Done. (by Dave 
            Peticolas, in 1.4.0)</p>
          </li>

          <li>
            <p><b>Auto-completion</b> Quick-fill should also
            auto-complete amount, memo fields. 
            <b>Status:</b>
            Done in 1.4.0, Dave Peticolas
            </p>
          </li>

          <li>
            <p><b>Autoincrement</b> Check numbers should
            auto-increment.  Hit + key in check number field
            (same keystroke as in quicken).
	    <b>Status:</b>
	    Done in 1.4.0, Dave Peticolas
	    </p>
          </li>

          <li>
            <p><b>Navigation</b> Menu navigation using the keyboard
            should be possible. Hit the Alt-F to get file menu, 
            hit Alt-FS to save.

            Similarly, tab-key navigation in the register 
            should be possible.
            <b>Status:</b>
            Done (in 1.3.x ?, Dave & all, partly inherited via gtk
            widget set.).
            </p>
          </li>

          <li>
            <p><b>Fly-Over Help</b> When the user pauses the mouse
            over a button, "fly-over" pop-up help windows should
            appear.
            <b>Status:</b>
            Done (in 1.3.x, inherited via gnome/gtk widget set).
            </p>
          </li>

          <li>
            <p><b>Grayed-out Form Help</b> Create grayed out
            entries in the ledger, titled "Memo", "Description",
            etc, helping users understand what should be typed into
            each field. <b>Status:</b> Done (by Dave?), as of version
            1.3.2(?)</p>
          </li>

          <li>
            <p><b>Key Bindings for Editing Text Fields</b>.  The input fields
            use the gtk text widget, which provides key bindings that
            are similar to the Netscape/emacs key bindings.
            This allows <em>e.g.</em> emacs-style ctrl-a,
            ctrl-k to do the right thing. 
            <b>Status:</b>
            Done (in 1.3.x, inherited via
            gnome/gtk text widget).</p>
          </li>
        </ul>
      </dd>

      <dt><a name="misc"><b>Miscellaneous Small Projects</b></a></dt>

      <dd>
        A variety of small internal projects. All have been 
        completed as of 1.6.0

        <ul>
          <li>
            <p><b>File Format</b>. Rework to use text file format. Will be 
                XML-based.
               <b>Status:</b> RLB, LewisMoss. Version 1.6.0 Done.
            </p>
          </li>
          <li>
            <p><b>Reconcile Window</b>.  
               Auto-pay credit card when reconciling credit card 
               accounts (Done, Dave).  
               Auto-add bank fee when reconciling bank accounts.
               (Not done?, Dave).
            </p>
          </li>
          <li>
            <p><b>Print Register Window</b>. Output register window to
               printer.
               <b>Status:</b> Done: there is a register report which
	       is printable, there is a button on register. Done in 1.6.0
            </p>
          </li>
          <li>
            <p><b># of decimal places in prices (penny stock)</b>. 
               Part of the big numeric overhaul. Done, Gribble, others, 
	       version 1.6.0
            </p>
          </li>
          <li>
            <p><b>gtkhtml</b>. Move to gtkhtml from gtk-xmhtml. 
               Done in 1.5, Grib.
            </p>
          </li>
          <li>
            <p><b>print</b>. Print reports, etc. Done in 1.5, Grib.
               This came 'for free' with gtkhtml.
            </p>
          </li>
          <li>
            <p><b>key-val pairs</b>. Add generic key-slot mechanism
               into accounts, transactions, journal-entries. Done in
               1.5.0, Grib.
            </p>
          </li>
          <li>
            <p><b>guid in fileio</b>. No longer relevant with new file
               format. Dave.
            </p>
          </li>
        </ul>
      </dd>


      <dt><a name="book"><b>Books, Accounting Periods</b></a></dt>

      <dd>
        Ability to close the book at end of the fiscal year. This
        consists of several steps: 

        <ul>
          <li>Permanently lock some transactions as non-editable.
              This should be straight-forward by using the <tt>
              reconciled</tt> field to indicate a <tt>locked</tt>
              value, and not allowing the GUI to edit locked
              records.
          </li>
          <li>Transfer the Income minus Expense for the book period
              to an equity account, so that each new period starts with
              zero income/expense balances.
          </li>
          <li>A mechanism to purge really old transactions from the
              database.
          </li>
          <li>Extensions to querying and reporting infrastructure ...
              The query changes might be painful ...
          </li>
          <li>
              A user should be allowed to 'delete' an account <em>
              only</em> if it has no transactions in the currently
              open book. 
              Of course, it's not deleted from the old books.
              From this last, we conclude that every chart of
              accounts should have a beginning and ending date (that
              match the book period), and the file format needs to
              support multiple charts ...
          </li>
          <li>Memorized Transactions ... Currently, transaction
              auto-completion works by auto-completing with the last 
              'similar' transaction.  This ability will get trashed 
              when books for the old year get closed, because there 
              won't be 'similar' transactions.
          </li>
        </ul>

        <p><b>Status:</b>
        <ul>
          <li>A mini-design Doc exists in <tt>src/engine/extensions.txt</tt>
	      A far more extensive, four-part proposal is ??? somewhere
	      in the mailing list archives (by Linas Vepstas, circa Feb-May 
	      2001)
	      </li>
        </ul>
        </p>
      </dd>

      <dt><a name="check"><b>Check Printing</b></a></dt>

      <dd>
        Create a check-printing ability. Include MICR (Magnetic Ink,
        Computer Readable) check printing abilities.
        <a href="http://dir.yahoo.com/business_and_economy/shopping_and_services/financial_services/banking/checks/">
        Yahoo Check Printing</a> provides a list of vendors & printers.
	<p>
	Print vendor/client/payee address on the check (so that check
	can be mailed with window envelopes.) This requires gnucash
	to integrate with addressbook.

        <p><b>Status:</b>
        <ul>
	  <li>More check formats need to be supported.
          <li>Done, except for address part, in version 1.4.0.
	      (gribble)
              </li>
          <li>Need a sample check/sample transaction to print out
              so that user can test printer.
          <li>MICR Fonts are available & brought to mailing list.
        </ul>
        </p>

      </dd>

      <dt><a name="wizards"><b>Wizards</b></a></dt>

      <dd>
        Create a set of wizards to walk through some of the more 
        complex tasks, such as new user setup, account creation, 
        QIF import, budget prep, obscure functional corners.
	<p>
	Wizards are great, but lets not throw away the denser GUI's.
	For 8-hour-a-day users, the wizards can be irritating. 
	A single, dense screen can be more efficient and nicer.
	So when adding wizards, don't dump GUI's !! (instead,
	make them 'advanced' features).

	<p>
	<b>Status:</b>
	The following not done:
        <ul>
          <li><b>Account Creation</b>
	    The account creation panel is somewhat busy. Maybe 
	    could use a wizard?
          </li>
          <li><b>Budget Setup</b>
            Setting up a budget.
          </li>
          <li><b>Obscure Corners</b>
            Various obscure corners of the application may be
            non-intuitive, and need wizard help.  e.g. stock splits?
            e.g. using foreign currency on a business trip?  
          </li>
	</ul>
	<b>Completed:</b>
        <ul>
          <li>
            <b>New User Setup</b> Provide
            a default Chart of Accounts, which will mostly consist
            of a default set of 'Categories' (Income/Expense
            Accounts). These are categories such as "Automobile
            Expense", "Bank Interest Income", and "Employment
            Income". The user should be able to select a default
            set of accounts, and have those created
            automatically.  Profiles: home-owner vs. renter
            non-for-profit (some non-profits are very very simple, 
            just a club).   Done in version 1.6.0, C. Champagne,
	    J LewisMoss
          </li>
          <li><b>QIF Import</b>
            QIF Import is just complicated enough that it needs 
            a wizard walk-through of the steps.  Grib,
	    version 1.6.0, Done.
          </li>
        </ul>
        <p></p>


      <dt><a name="arrangements"><b>Arrangements</b></a></dt>

      <dd>
        An "application arrangement" is the defining look-n-feel of an application.
        The idea is similar to, but not the same as 'skins'/'themes'.  Its similar
        to, but not the same as allowing a user to set 'preferences'.  Its similar 
        to, but not the same as, allowing a user to generate customized financial 
        reports.  In the context of GnuCash, a 'arrangement' should be a file
        (that can be traded by users, uploaded and shared) that controls important
        aspects of how the application is configured.
        <p>
        In particular, the GnuCash Arrangement should include the following:
        <ul>
        <li>A list of sample/initial accounts.  These might be tailored for a 
            home user (groceries, gas, electric), an apartment dweller 
            (rent, laundry), or different kinds of business users.
            Because these sample accounts appear in the Arrangement file, 
            it becomes easy to create & distribute customized arrangements.
        <li>A list of pre-defined reports and graphs.  The kind that you'd find
            for a home user might be different than for a person managing a stock
            portfolio, which is in turn different from what a business might need.
            The Arrangement File should include install-specific customizations, such 
            as the report headers, footers, etc.
        <li>Hint of the day.  The types of 'hint of the day' would be different 
            for new users, than it would be for advanced users.  Thus, different
            arrangements would have different catalogues of 'hint of the day'.
        <li>Menu Contents & Navigation.  New users might be presented with a simple set
            of menu contents.  'Power Users' might be presented with deep, nested
            sets of menus, with oodles of features.
        <li>Register Layout.  The layout of the register might be customized for
            different countries: e.g. in Germany, a different type of electronic
            banking seems to require the display of account numbers in separate
            columns in the register.
        </ul>
        A good arrangement infrastructure will not only allow gnucash to be configured
        for different application domains, but also will allow users to fine-tune
        their own preferred arrangement.   It can also simplify the code base: 
        instead of having two products, a home-user application, and a small-business 
        application, each with a different code base and #defines and what not, instead,
        we have one code base, and different arrangements for each.
        However, most importantly, the arrangements should be easy to share between users.
        They should be such that users are encouraged to trade and use arrangements,
        and to create new ones that suit their needs.
        </p>
        <p>
        The idea for arrangements was inspired by 
        Adam Curry's commentary on
        <a href="http://adamcurry.editthispage.com/stories/storyReader$161">
        radio formats and Napster</a>.
        </p>
	<p>
	<b>Status:</b>
	Not started. Individually, all these cusomizable things exist
	here and there in gnucash, but they cannot be shared between
	users: a gnucash user cannot mail her favorite 'arrangement'
	to her friend.
	</p>


      <dt><a name="userpref"><b>User Preferences, Session Management</b></a></dt>

      <dd>
        A dialog system and file format for manipulating user
        preferences. Preferences include things like default
        currency, register layout and colors, etc. 

        <p>What are some of the competitive preference-handling
        technologies? Lets get some URL's here ... Following the
        Unix tradition, there is no global preferences registry.
        Note that session management and preferences are related
        things ... sort-of. Right now, we don't treat them as such
        ...</p>

        <p><b>Status:</b></p>
	Done, more or less, version 1.6.0.

        <ul>
          <li>Works real good; lots of preferences in the GUI.
              Implemented in home-grown scheme. (version 1.4.0,
	      rlb)</li>

          <li>These are saved in the '.gnucash/config.auto' file.
              The current file format is raw scheme code, rather
              delicate to tweak by hand ...</li>
	  
          <li>Session management mostly works, but doesn't use the 
	      sawmill/gnome/X ICCCM system.  GnuCash remembers MDI
	      based reports, restart reopens in same state. Sizes
	      and shapes and positions are remembered.
	      Done in version 1.6.0
              </li>

          <li>Independently of session management, the register
              windows should remember how big they were last time they
              were popped up, and they should pop up the same size, again.
              The app should remember these sizes from invocation to
              invocation. Done in version 1.6.0, but seems a bit buggy.
	      </li>

        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="architecture"><b>Architecture Review</b></a></dt>
      <dd>
        The application is wired together partly with C, partly
        with Scheme. The architecture of the wiring and how scheme
        is fit in needs to be reviewed, with a general overview
        created so that additional extensions may be added in a
        straightforward manner. 

        <p>The overall architecture is envisioned thus:
        All code, including the transaction engine, the file I/O
        routines, the menus, and the ledger, will be abstracted
        into compact modules that can function independently of
        each other. At the highest level, there will be a
        infrastructure with extension language interfaces that will
        "wire together" the various modules.</p>

        <p>Such "wiring together" will consist of a dispatch
        infrastructure that will allow arbitrary menu entries to be
        hooked to arbitrary modules. The configuration for menu
        entries, and their associated callbacks, will be specified
        in an extension-language configuration file. At the final
        stages, it is <em>highly</em> desirable to be able to, in
        some manner, import new modules <em>without</em> requiring
        that the application itself be recompiled and relinked.</p>

        <p><b>Status:</b></p>

        <ul>
          <li>
            Scheme/Guile is the central extension language.  Guile
            interfaces auto-generated using g-wrap.
          </li>
          <li>
            Optional interfaces to the data engine (for, e.g.
            perl) can be generated using 
            <a href= "http://starship.skyport.net/crew/beazley/swig.html">
            SWIG</a>.
          </li>
          <li>
            Dave to collate & edit architecture documents. 
            RLB to provide diagrams.
          </li>
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="alerts"><b>Recurring Transactions, Calendar Alerts,
          Scheduled Transactions</b></a></dt>

      <dd>
        (1)Add support for automatic, recurring transactions, <em>
        e.g.</em> mortgage payments, fixed-interest bonds, regular
        salary checks, regular gas/phone/electric bills, <em>
        etc.</em> 

        <p>(2) Recurring bills, salary income, etc. are simpler to
        handle, since they don't have interest rates, balloons,
        etc. They do/will have multiple splits (<em>e.g.</em>
        payroll gross, fica, futa, income taxes, payroll net).</p>

        <p>(3)Provide list of upcoming &amp; recently paid
        bills/scheduled payments/scheduled deposits for the next
        1,2,3,6,12 months. Historical view shows payments crossed
        out (!?)</p>

        <p>(4)Loans &amp; mortgages are one of the more complicated
        recurring transactions.  Typically, there might be a years
        worth of smaller payments, then a long string of larger
        payments, followed by a balloon.
        </p>
         
        <p>(5)Provide a calendar-display of upcoming &amp; past
        scheduled payments. Clicking on a calendar day should raise
        up editable list of transactions. Calendaring should
        include generic red-lettering of important dates: taxes
        due, insurance renewal dates, domain registration renewal
        dates, ISP contract expiration date :-). These may or may
        not be associated with transactions. Memo's should be
        possible. Pop-ups should happen when dates get close.
        Technology: best bet is the Ximian Evolution Calendar
	component.</p>

        <p><b>Design Notes:</b> Most alerts &amp; data storage
        should be driven out of the engine. This will enable
        multi-user, distributed use. <b>Note:</b> alerts should be
        piggy-backed on a general alert infrastructure within the
        engine, viz, registered callbacks when balances change, so
        that windows can be redrawn. Not clear on if/how calendar
        events might be server-ified. (On the other hand, a good
        calendar should be server-ified, and thus viewable by
        secretaries, co-workers, etc.)</p>

        <p>More complex financial instruments may need a
        guile-based extension mechanism to compute values ....
        simple interest/mortgage calculators should be done in C in
        the engine ... (<em>e.g.</em> depreciation schedules ...
        under us tax law, a variety of different schedules are
        allowed ... )</p>

        <p>May need interfaces to email for emailed alerts.</p>

        <p>Plot forecast graphs based on scheduled income &amp;
        payments ... is this tied into budgeting ????</p>

        <p><b>Status:</b></p>

        <ul>
          <li>Need to create design doc, need to implement engine
          pieces, need to hunt down gnome-calendaring bonobo.</li>
          <li>Preliminary work started.
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="budget"><b>Budgeting</b></a></dt>

      <dd>
        Ability to create a budget (<em>i.e.</em> - estimates of
        future expenditures). Reconcile actual expenditures against
        future expenditures. Create simple, step-by-step 'financial
        plan' budgeting GUI's: 

        <ul>
          <li>Home purchase planner</li>

          <li>Retirement planner</li>

          <li>College tuition planner</li>

          <li>Debt reduction planner</li>

          <li>Scrimp-n-Save planner</li>

          <li>Special purchase planner (big ticket items)</li>
        </ul>
        Create a summary budget/track-record budget report that a
        professional financial planner/advisor could use. 

        <p>Note that the above 'step-by-step' budgeters will have a
        very very different GUI than what the budgeting system
        required for a small-business might look like.</p>

        <p>Note that the utility of budgets is greatly enhanced by using
        them with '<a href="#classes">classes</a>'. 

        <p><b>Status:</b></p>

        <ul>
          <li>A design doc has been submitted by Bob Drzyzgula.
          Take a look at <tt>./src/budget.txt</tt> in the source
          directory.</li>

          <li>Bryan Larsen has begun work .. it's scheme based ...
          Dave Peticolas has some GUI roughed out ...</li>

        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="classes"><b>Classes</b></a></dt>

      <dd>
        Ability to mark certain journal entries as belonging to 
        a 'class', so that expenses (or income) can be categorized
        in more than one way.  For example, the expense of a trip
        might include food, travel and lodging, and thus be spread over
        three different expense accounts.  None-the-less, we want all
        of these entries to be marked as being in the same class.
        (Alternate names: 'job costing' is the report that's generated,
        'cost center', 'cost pool', 'pooling')
        Note that classes can be particularly useful when used with
        budgets: viz. I set aside $10K in the budget for some activity,
        then deduct the actual costs.  Note that it should be possible
        to roll the remainder over to somehere else (!) 
	<p>
	Confusion: isn't this what the 'action' field is supposed to do?
	The 'action' field is under-utilized.

        <p>
        This requires the following:
        <ul>
        <li>Ability to report by class/action
        <li>Ability to query by class/action.
        </ul>
        </p>

        <br>
        <br>
      </dd>

      <dt><a name="testing"><b>Automated Test Suite</b></a></dt>

      <dd>
         Build automated test suite, including:
         <ul>
           <li>File IO consistency check. Done, 1.6.0, LewisMoss
           <li>Currency math correctness. Done ?? Grib.
         </ul>
        <br>
        <br>
      </dd>

      <dt><a name="quickim"><b>Quicken(TM) Import</b></a></dt>

      <dd>
        Ability to import Quicken QIF files. Both MSMoney and
        Quicken use QIF files to export data.  Need both wholsesale
	data import, and incremental (staged) merge.

        <p><b>Status:</b></p>

        <ul>
          <li>
            Quicken import is implemented and mostly works. 
            (Bill Gribble, Done, in version 1.4.0)
          </li>
          <li>
            Need a QIF Import wizard (there are several non-intuitive
            steps that need to be performed during import.  
            A dialogue wizard seems like the best idea to carry 
            through this process. (grib, done in 1.6.0)
          </li>
          <li>
            Work needs to be done for recurring transactions, etc.
          </li>
          <li>
            QIF processing, as used for on-line banking, is <em>
            in prototype form</em> (for 1.6.1 ??)
            Note that since banks use QIF, the <em>correct</em>
            way to updated 'cleared' reconcile state is through
            QIF on-line import.
            On one side, we have existing recorded transactions;
            on the other, the latest bank statement, in QIF
            format.
            </p>
          </li>
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="iifim"><b>IIF Import</b></a></dt>

      <dd>
        Ability to import IIF (Intuiut Interchange Format, used by Quickbooks)
	files, quickbooks, some upsacle accounting packages use this format.

        <p><b>Status:</b></p>

        <ul>
          <li>
	    Sample files checked into sample directory.
	    No formal documentation known.
          </li>
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="quickex"><b>IIF Export</b></a></dt>

      <dd>
        Ability to export Intuit IIF files. 
	The IIF format is more rational than the QIF format,
	and other 'real' accounting apps support IIF.
        Several design alternatives are apparent:

        <ul>
          <li>
            A special 'report' that writes out qif could be
            created. 
            This would use the 'reports' infrastructure to
            generate QIF's.
          </li>

          <li>It is fairly easy to traverse the data in the engine
              to write out qif files. This is not hard. Just do it.
	      </li>
        </ul>
        <br>
        <br>

        <p><b>Status:</b> not started</p>
      </dd>

      <dt><a name="quote"><b>Stock Quotes, Price Quotes</b></a></dt>

      <dd>
        Add ability to obtain stock, mutual fund, and currency trading
        data from news agencies, web pages.  
        Add ability to download historical prices as well.
        (<em>e.g.</em> get 5-year history of mutual fund
        performance vs. DJIA).

        <p>Right now, stock prices are stored in a separate, simple pricedb.
        </p>

        <ul>
          <li>Prices need to have several different status states.
	      One state is 'critical/audited', i.e. reviewed by a human,
	      and important for understanding a historical transaction.
	      Less mportant may simply be 'audited': i.e. reviewed by a 
	      human, but not a critical price.  Lowest level: 'live data'
	      something that was gotten off the net, may be wrong, may 
	      be right, who knows, who cares.
          </li>
	  
          <li>Add to this the idea that we should probably store other
              'technical' stock data, such as share volume, high/low/close,
              daily volatility, etc.
          </li>

	  <li>Need access to historical quotes, for graphing charting 
	      of historic portfolio perfformance.
          </li>
        </ul>

        <p><b>Status:</b></p>

        <ul>
          <li>
          <a href="https://sourceforge.net/project/?group_id=4232">
          Finance::Quote.pm</a> is now a separate development project at
          SourceForge.  Its a perl module.
          It can obtain stock quotes from Yahoo 
	  (NYSE), Yahoo-Europe, Fidelity Investments, T.Rowe Price, 
	  TIAA-CREF, others. Also handles currency exchange rates.
	  </li>
	  
	  <li>A scheme wrapper allows prices to be
	  fetched from GUI. Done, version 1.6.0, rlbrowning.</li>
	  
          <li>
          Commandline-flag replaces script file <tt>gnc-prices</tt> 
	  perl script). Suitable for use with cron jobs.
	  (version 1.6.0)
          </li>

          <li>A separate, historical-quote module can be found at the
          <a href="https://sourceforge.net/project/?group_id=2403">QuoteHist</a>
          sourceforge site.  It might be a good idea to fold this
          together with the Quote.pm  module !?
          </li>
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="install"><b>Install</b></a></dt>

      <dd>
          Install on Redhat, Caldera, Corel, SuSE, FreeBSD, TurboLinux,
          etc.  Possibly use a 'configure'-like way of dealing with
          install inconsistencies.
        <p></p>
      </dd>

      <dt><a name="currency"><b>Multiple Currencies</b></a></dt>

      <dd>
           Need to support multiple currencies. 
           Work is needed in the GUI. The engine currently supports
           multiple currencies by treating them as securities, thus
           allowing currency trading. The currency-trading register
           needs a complete overhaul as it is obtuse and
           unintuitive. Weird stuff is in weird columns.
        </p>
        <p>
           A simplified way of dealing with one-shot currency
           exchanges needs to be implemented, essentially just a
           simple calculator pop-up.  This might be handy for the 
           occasional business traveler or tourist with some minor 
           currency trades.
        </p>
        <p>
           Implement the 'correct' way of handling this when user
           is working in multiple currencies on a regular basis.
        </p>
        <p>
           <a href="https://www.cloanto.com/specs/seriff.html">SERIFF</a>
           Simple Exchange Rate Information File Format.  Completely
           *.ini-centric in layout and design, but otherwise seemingly
           quite complete. 
        </p>

        <p>
        <b>Status:</b> 
           <ul>
           <li>Need to rethink whether the one-shot exchanges
               should in fact be recorded full-fledged in the engine.
               Also: Euro support is currently hacked in: the EURO is treated as
               a 'special' currency. Virtually all the Euro code can be fully
               generalized (and should be).
           <li>New split architecture should store quantity and value, and 
               never the price.  This will simplify currency movements 
               between accounts, without requiring/forcing the use of a 
               currency trading account.  (this also solves problems with 
               rounding that occur when a price is explicitly specified.)
               Grib & dave are working this for next release.
           </ul>
        </p>
     
      </dd>

      <dt><a name="double"><b>Forced Double-Entry</b></a></dt>

      <dd>
        The system supports double-entry: every transaction
        indicates a pair of accounts: one is debited, and one is
        credited. 

        <p>Double-entry is a powerful way of ensuring the integrity
        of of the financial data. Currently, while double-entry is
        supported, its use is not enforced: the user <em>can</em>
        create dangling transactions, where only one account is
        indicated.</p>

        <p>Although this is acceptable for home use (arguably
        desirable, since it allows the casual user the simplicity
        they desire), it is not acceptable for business use. (The
        counterargument is that casual users that aren't
        accountants need all the help at getting things right that
        they can get.)</p>

        <p>It must be possible to enforce double entry, so that a
        transaction cannot be completed until two accounts have
        been specified.</p>

        <p><b>Restricted Double</b> Note that sometimes, the words
        'single-entry' have a an alternate meaning: they can mean
        'a double entry account which can only be credited, or
        debited, but not both'. We need to implement this.</p>

        <p><b>Current status:</b>

        <ul>
          <li>April 1998 -- The engine has a couple of flags in it
          that control double-entry behavior: it can be made lax or
          strict, however, they are compiled in, and there is no
          way to change them from the GUI.</li>

          <li>Dec 1998 -- Scrubber functions implemented to crawl
          through data, and find all unbalanced or orphaned
          transactions.</li>

          <li>May 2000 -- Default will be changed to double-entry
          always. It will not be possible to disable this and move
          to single-entry.</li>
        </ul>
        </p>
      </dd>

      <dt><a name="401K"><b>401(k), Retirement Savings Plans</b></a></dt>

      <dd>
        401K, 403, IRA, Roth IRA, SEP, Keogh ... 
        Retirement Savings Plans often do not put a high
        priority on tracking costs, as the tax implication is that
        amounts are taxable upon withdrawal, meaning that there is
        little necessity to track capital gains. (huh??)
        <p>
        </p>
      </dd>

      <dt><a name="note"><b>Annotate with News Stories</b></a></dt>

      <dd>
        Download, save, annotate investment news and research. 
        Provide a way of storing news stories with accounts, and
        possibly annotating individual transactions in the same
        way.
        <p></p>
      </dd>

      <dt><a name="searchdocs"><b>Searchable Documentation</b></a></dt>

      <dd>Need to add a 'meta keyword' tag to the documentation
        pages, this will help the search engine (<em>e.g.</em> 
        <a href="https://www.htdig.org/">htdig [DEAD LINK]</a>) better categorize the
        help. <a href="https://www.senga.org/mifluz/html/">Mifluz [DEAD LINK]</a>
        might be more embeddable ... I am told that htdig-API is in
        good solid condition for this, but undocumented.
        <p>

	<b>Status:</b>
	Done, using a simple keyword search, homegrown.  The only 
	problem is it doesn't support compound expressions.
	</p>
      </dd>

      <dt><a name="reconcile"><b>Reconcile Auditing</b></a></dt>

      <dd>When a collection of transactions get processed through the
        reconcile dialogue, user needs to be able to add a note to this,
        i.e. this set of JE's will be treated as a group.  The note
        (and date) can be later called up as a part of an audit
        procedure.  The act of reconciliation is treated as a
        historical event that needs to be logged.
        <p></p>
      </dd>

      <dt><a name="loan"><b>Loan and Mortgage Calculators</b></a></dt>

      <dd>
        Provide a variety of simple GUI utilities to allow user to
        calculate the future value of loans, mortgage payments,
        interest payments, etc. 

        <p> Consider the following dialogue layout:</p>
<pre>
loan amount $_____________ currency _________ (pull-down menu)
Remaining balance $___________
Payment amount $___________
balloon  payment $_____________
other payment $________  (e.g. escrow, tax)
Payment frequency (weekly/monthly/bimonthly/quarterly/yearly)
loan start date mm/dd/yy   length -----(weeks/months/years/payments)
loan time left (number of days/weeks/months, rounded)
number of payments left
interest rate  %__________________
payee ____________
pay-from account __________________
next due date mm/dd/yy
</pre>
        Note that in the above, not all fields are independent:
        some can be calculated from others. The <tt>other
        payment</tt> should bring up a mini-register, allowing user
        to add any number of splits.<br>
        <br>
         
        <p><b>Status:</b></p>

        <ul>
          <li>There is an implementation of the calculation routines by
              Terry Boldt in the development branch. There is an initial
              GUI implementation of the calculator by Dave.
          </li>
        </ul>
        <br>
        <br>
      </dd>

      <dt><a name="overdraft"><b>Overdraft Alerts</b></a></dt>

      <dd>
        Overdraft alerts are pop-ups that pop up whenever the user
        enters a transaction that would move an account below some
        minimum balance, or above some max balance (for a bank
        account) or an expense/spending limit is reached (on an
        expense account). A similar but different alert can be
        implemented for price highs &amp; lows. Note that these
        alerts do <em>not</em> require any sort of calendaring or
        recurring transaction support. 

        <p>Design requirements: implement multiple (not just two)
        alerts for any account type. Alert should consist of</p>

        <ul>
          <li>value point or price point</li>

          <li>movement direction</li>

          <li>'is active' boolean flag (<em>i.e.</em> Should be
          possible to 'turn off alert' without deleting it)</li>

          <li>memo text</li>
        </ul>

        <p><b>Status:</b>
        <ul>
          <li>Not Started.</li>
        </ul>
        </p>
      </dd>

      <dt><a name="tech"><b>Technical Stock Analysis</b></a></dt>

      <dd>Provide technical stock analysis graphs, <em>e.g.</em>
          volume, 90 moving avg, beta, etc. See gstalker for example of
          how to do it ...
          <p></p>
      </dd>

      <dt><a name="sink"><b>Asset Depreciation, Sinking Funds, 
           Amortization Schedules</b></a></dt>

      <dd>Need to
          support different depreciation schedules (see IRS books for
          that).  Asset depreciation is complex; there are many
          different depreciation schedules, and these vary from 
          country to country, and change when new tax laws are
          implemented. It might be hard for free software to provide
          a no-cost subscription to updated depreciation modules.
          <p></p>
      </dd>

      <dt><a name="ofx"><b>OFX support</b></a></dt>

      <dd>
        Provide the SGML DTD parsers to handle the OFX reports that
        many banking institutions are providing, or will soon be
        providing, to retail customers. See below for OFX
        references. 

        <p>OFX is an open spec from Microsoft, Intuit, and
        Checkfree, and which will be supported by Integrion. The
        OFX DTD's are included in the 1.1 distributions. See <a
        href="http://www.ofx.net">OFX Home Page</a> for
        details.</p>

        <p>There are two ways to build an OFX parser. One way is to
        build a compile-time DTD parser that treats the DTD as if
        it were an IDL, and generates C language stubs for a
        parser. This approach was attempted and abandoned because
        it leads to fragile C code and a very large binary.</p>

        <ul>
          <li>The parser is fragile because minor DTD
          non-compliances are hard to parse, handle and recover
          from.</li>

          <li>The parser is huge because the DTD results in
          hundreds of (C++) objects being generated.</li>
        </ul>
        The other method would be to perform run-time DTD parsing.
        This is attractive particularly because it is a more
        commonly-used approach; there are a variety of XML tools
        available that provide this function. 

        <p>Run-time parsing may be slower, but on the OFX client
        side, this should not be a bottleneck.</p>

        <p><b>Status:</b></p>

        <ul>
          <li>A compile-time parser was developed and
          abandoned.</li>
        </ul>

        <p>Note that the organizations developing OFX are looking
        to use XML as their "formats of the future;" this may
        encourage the use of one of the many XML parsers available
        for UNIX.</p>
      </dd>

      <dt><b>Other on-line support</b></dt>

      <dd>
<pre>
&gt;&gt; the German T-Online
&gt;&gt; homebanking system BTX.
&gt;&gt;
&gt;&gt; I Germany we have a very popular online homebanking system,
&gt;&gt; based on the T-Online BTX (Datex-J) system. All of the
&gt;&gt; commercial homebanking software packages like MS-Money or
&gt;&gt; Quicken work with that online system. With that system,
&gt;&gt; you can retrieve  account data from your bank, and also
&gt;&gt; send your transfers.
&gt;&gt;
&gt;&gt; I am using since more than 2 years a GPL software written
&gt;&gt; by a former colleague of mine, Niek Busscher, to work with
&gt;&gt; the T-Online homebanking system. That software package with
&gt;&gt; the name ZKA4BTX is very unknown, since Niek published it only
&gt;&gt; by email.
&gt;&gt;
&gt;&gt; Some words to the features of ZKA4BTX :
&gt;&gt;
&gt;&gt;  - Completely written in Tcl
&gt;&gt;  - Uses Xcept as a BTX browser
&gt;&gt;  - Retrieve account data from multiple banks
&gt;&gt;  - Send transfers, using TAN
&gt;&gt;  - Export retrieved account data to CBB, Xfinans and QIF files      
&gt;&gt;  - Export retrieved account data to CBB, Xfinans and QIF files
&gt;&gt;
&gt;&gt; With a simple click to an icon on my desktop, ZKA4BTX logs into
&gt;&gt; T-Online, gets all my account data from several banks, and writes
&gt;&gt; (adds) it to my CBB, Xfinans or GnuCash (QIF) files.
&gt;&gt;
&gt;&gt; Another very important thing is that I can do all my transfers
&gt;&gt; offline, editing a transfer sheet, and ZKA4BTX sends these
&gt;&gt; transfers in one step to my bank.
&gt;
&gt;One thing we could do in the short-medium term is have gnucash
&gt;launch ZKA4BTX to get the data, export it to QIF, and then load
&gt;it in, all through one command.
</pre>
      </dd>

      <dt><a name="tab"><b>Tab-delimited ASCII file format</b></a></dt>

      <dd>
        People <em>like</em> to be able to read file contents in
        ASCII; there are many Unix tools for manipulating ASCII. An
        ASCII equivalent of the current file format should be easy
        to develop ... just substitute the writes with <tt>
        printf()</tt>s. 

        <p>The tab-delimited format should be compatible with that
        of <tt>/rdb</tt>, aka <a href=
        "ftp://ftp.rand.org/pub/RDB-hobbs/">RAND/Hobbs /rdb</a> or
        <a href=
        "ftp://ftp.linux.it/pub/database/RDB/nosql-0.8.tar.gz">
        NoSQL.</a> (NoSQL is available as part of the <a href=
        "https://www.debian.org">Debian GNU/Linux</a> distribution,
        for instance.)</p>

        <p>The <tt>/rdb</tt> format is thus:</p>
<pre>
field-name  tab  fieldname  tab fieldname   \n
------------------------------------------  \n
value       tab   value     tab value       \n
value       tab   value     tab value       \n
etc ...
</pre>

        <p>It is a very simple, very basic flat table format. The
        use of <tt>/rdb</tt> with GnuCash should try to match with
        SQL schemas as much as possible in order to minimize I/O
        complexity and incompatibility.</p>
      </dd>

      <dt><a name="tax"><b>Tax Preparation</b></a></dt>

      <dd>
        Gotta prepare those taxes. 
        W-2, W-3, 941, 940 Processing.

        <ul>
          <li>
            TurboTax --
            categorize items according to different tax
            schedules
          </li>

          <li>VAT -- Value Added Tax. Varies from country to country.
          </li>

          <li>Estimate income taxes.
              Estimate itemized deductions, find potential
              deductions, categorize them</li>
        </ul>
        <p></p>
      </dd>

      <dt><a name="palm"><b>Sync with Palm Pilot organizers</b></a></dt>

      <dd>There are Quicken-workalikes that run on the
          PalmComputing platform; it would be good to inter-operate
          with this. See
          <a href="ftp://ryeham.ee.ryerson.ca/pub/PalmOS/">PalmLink</a> 
          and <a href="http://www.orbits.com/Palm/">Palm & Linux</a>.
          <p></p>
      </dd>

      <dt><a name="emerg"><b>Emergency Records Organizer</b></a></dt>

      <dd>Put together a single-page report showing critical info
          about accounts, etc.
          <p></p>
      </dd>

      <dt><a name="logging"><b>Logging, Crash Recovery</b></a></dt>

      <dd>
        Logging serves two purposes: (1) return the system to the state
        it was in on some earlier date.  (2) recover from a crash.
        Probably need two distinct mechanisms to support this.  The
        mechanisms are (A) backup copies. These can be compactly handled
        via RCS (actually, deltax) for storage.  (B) Logging.  Write
        out to disk each & every change made.
        </p>
        <p><b>Status:</b>
        <ul>
          <li>Crude transaction logging/auditing in place; should
          be suitable for error/crash recovery but has not been
          "tried by fire."</li>

          <li>Backup files automatically created and
          time-stamped.</li>
        </ul>
        </p>

        
      </dd>

      <dt><a name="engine"><b>Enriched Engine, Financial Objects</b></a></dt>

      <dd>
        The current system makes a distinction between the data
        (account, transaction) and they GUI that displays it. The
        data is embedded within and controlled by the "Engine",
        which is a set of routines to access accounts,
        transactions, etc. The engine serves as a kind of a dynamic
        cache between the permanent data repository (file, sql db)
        and the GUI. 

        <p>The current engine is rather simple: it provides support
        for accounts, account hierarchies and transactions
        consisting of multiple entries.</p>

        <p>Many of the features described elsewhere will require
        that the engine have a far richer, more sophisticated data
        model, including such things as:</p>

        <ul>
          <li>Linking to "Address Info" ( <em>e.g.</em> names,
          addresses)</li>

          <li>Transaction identifiers</li>

          <li>Part numbers, SKU IDs</li>

          <li>Interest rates</li>

          <li>Budget policy</li>
        </ul>

        <p>Note: it makes no sense at this point to make the engine
        API much richer than what the GUI can currently
        support.</p>

        <ul>
          <li><b>Locks</b> When splits are implemented, and the
          parent transaction has been marked as cleared/reconciled, 
          the record
          should be locked, so that further modifications to the
          amount can't be performed (or at least, a warning is
          generated to prevent accidental garbaging up of old
          transactions).</li>
        </ul>

        <p><b>Current Status:</b></p>

        <ul>
          <li>
            <tt>BeginEdit()/RollbackEdit()/CommitEdit()</tt>
            routines mostly in place, 
            these "Transaction processing constructs" should
            simplify creation of an SQL back end, or some other
            more sophisticated transactional server.
          </li>

          <li>Multiple currency support is present but still pretty
              "raw."</li>

          <li>Query engine has been broadly extended (Bill Gribble).
              Documentation for Query Engine??</li>

        </ul>
        <p></p>
      </dd>

      <dt><a name="sql"><b>SQL I/O</b></a></dt>

      <dd>
        A module is necessary to allow data to be fetched from an
        SQL database, and for that database to be updated. 
        There has been <em>much</em> discussion about this on
        mailing lists both for GnuCash and 
        <a href="http://www.menet.umn.edu/~curt/cbb/">CBB [DEAD LINK]</a>.
        Major points have included:

        <br>
        <br>
        <ul>
          <li>The use of a database allows only that data which
              is actually <em>in use</em> to be loaded into
              memory.  This permits managing larger sets of
              transactions more efficiently.
          </li>
          <br><br>

          <li>It also allows data to be pushed out to the DBMS
              <em>immediately after entry,</em> rather than waiting
              for the user to "save the books."
          </li>
          <br><br>

          <li>Using a client/server SQL database might make it easier
              to turn GnuCash into a multi-user system.
          </li>
          <br><br>

          <li>By using a well-known DBMS, outside programs are
              provided a well-defined way of getting at, and
              perhaps even modifying, GnuCash data. 
              (Actually, this is not true: GnuCash already provides
              a uniform, well-documented, preferred data access API.  
              As long as this
              API is used, there is some guarantee that data is stored
              in a self-consistent fashion.  Not using the GnuCash 
              programming interfaces risks corrupting the data.
              Direct access to the data is dangerous and discouraged.
              Furthermore, The API is guaranteed to be backwards
              compatible with a variety of data storage formats.
              Due to enhancements, the actual form of the data stored in
              a flat file, or in the SQL database, may change without 
              warning.)
          </li>
          <br><br>
          <li>
            Those SQL databases available on Linux tend to involve
            considerable <em>administrative</em> overhead in terms
            of getting them set up. 
            This may be a minor cost to a business enterprise
            that routinely hires Database Administrators.
            It is <em>not</em> acceptable to require this of
            naive users that may find "simple" things like
<pre>
% su -
Password:
# cd /tmp
# rpm -i gnucash-4.1.3.i386.rpm
# exit
</pre>
            to be challenging.
          </li>
          <br><br>

          <li>
            It might be useful to use an embedded database engine
            like unto <a href="https://www.sleepycat.com/">Sleepycat
            DB [DEAD LINK, now owned by Oracle]</a>,
            <a href="ftp://koobera.math/uic.edu/www.cdb.html">cdb</a>,
            or something like 
            <a href="https://www.opengroup.org/public/prods/dmm4.htm">
            ISAM</a> (Note CQL++ supports ISAM access methods), or
            even an embedded SQL engine such as 
            <a href="https://www.ispras.ru/~knizhnik/gigabase.html">
            GigaBASE [DEAD LINK]</a>.
            The reasons to do so include ... ???
          </li>

          <br><br>
          <li>
            GnuCash presently uses a document-oriented model, where
            the <em>entire</em> set of books are loaded in, and
            dumped out, all at one fell swoop. 
            GnuCash needs to be modified to access the database
            in a transactional manner. This is at least partly
            implemented with the <tt>Begin()/End()</tt> constructs
            in the engine.

            <p>
            Some transactional thoughts: entire SQL
            tables/databases do not need to be locked while the
            user is editing a transaction via the GUI.
            Instead, an optimistic approach, similar to that
            employed by CVS (concurrent version system, a mechanism
            for storing versions of source code) could be used: if
            the edits conflict with changes made by others, edits
            are be rejected en-masse, allowing the user to merge
            and correct their changes.
            Important note: updating SQL does <em>not</em>
            require locks to be held for extended periods of
            time!
            </p>
          </li>

          <li>
            The SQL engine chosen should be fully transactional,
            passing the 'ACID' test (Atomicity, Consistency,
            Isolation, Durability). 
            Note that 
            <a href="http://openacs.org/why-not-mysql.html">MySQL 
            does not satisfy the 'ACID' criteria</a>.
          </li>
        </ul>
        <p>
	<b>Status:</b>
	Done, more or less, gnucash version 1.6.0, Linas Vepstas.
	There's still a laundry list of things that need to be 
	cleaned up, see the README file in src/engine/sql/README.
	
	</p>
      </dd>

      <dt><a name="multiuser"><b>Multi-user Support</b></a></dt>

      <dd>
        Multi-user support should be added with either an SQL
        backend to the engine, and/or through CORBA interfaces to
        the engine. 
        Another possibility is to create a web application
        server, and have users do much/most of I/O via a web
        interface, possibly using the register object as a browser
        plugin.
        The following industrial-strength features are
        needed:
        <br><br>

        <ul>
          <li>transaction-oriented queuing of updates</li>

          <li>event subscription channel for updates</li>

          <li>user authentication</li>

          <li>user authorization</li>

          <li>non-repudiability (needed only for peer-to-peer??)</li>

          <li>encryption of network connections</li>
        </ul>
        <p>
	<b>Status:</b> Partly done.  (gnucash 1.6.0, Linas)
	The postgres backend fully
	supports multiple simltaneous users. This includes 
	events for automatic updates of all GUI displays.
	However, the GUI support is rough, no GUI dialog 
	for user/password.  
	</p>
      </dd>

      <dt><a name="addressbook"><b>Address Book</b></a></dt>
      
      <dd>
        Provide support for client/vendor/customer address books,
	including street address, eamil, phone.  Also: to-do lists,
	a mini-contact manager (when is last time this person 
	was paid? what did they say on phone the last time we 
	sent them a check? Is there a dispute?)
	<p>
	Propose: use Ximian Evolution contact manager/to-do lists.
	</p>
      </dd>
      
      <dt><a name="arap"><b>Accounts Payable, Receivable</b></a></dt>

      <dd>Add features to track sales receipts and other pending
          sources of income, as well as owed sums.  
          <ul>
          <li>Need new account type 'ar' and 'ap'.  When this account type is
              selected, the register display, etc. is slightly different, as below:
          <li>Add field to register called 'date due'.  The date could be
              entered as 'date of transaction +30days'. etc.  The account
              could have a default: entries always default to +30 or +45 days
              or whatever.  
          <li>Create a report to match 'date due' to current date, and report
              overdue balances ...
          <li>Create Account aging report: show (average) age of 
              amount-due/amount-owed.   
          <li>Create a projected cash flow report: showing projected
              future payments based on date due.
          <li>Somehow, automatically match invoices to payments.
              When an invoice has been paid off, then there should be a 
              view mode where the invoice and its payment is no longer shown 
              (i.e. so that only outstanding, unpaid entries are shown ...)
          <li>create report showing everything but the a/p:
              Here's an example.  I buy a chair for a friend, and three
              days later he pays me back.  What I've been doing is ...
<pre>
>   1/12/01  Credit    -$100
>            A/R       +$100
>   1/15/01  Cash      +$100
>            A/R       -$100
</pre>
             To make it less painful to read and understand, the 
             report should look like:

<pre>
>   1/12/01 Credit -$100
>   1/15/01 Cash   +$100
</pre>
             i.e. there would be a new kind of 'transaction report' that 
             would pair up transactions in this way, showing things 
             'as if' the A/R didn't exist, and 'as if' a transaction
             was spread over a bunch of days.

          </ul>
          <p></p>
      </dd>

      <dt><a name="payroll"><b>Payroll</b></a></dt>

      <dd>
        Payroll introduces a <em>sizable</em> amount of complexity
        in terms of the need to comply with constantly-changing
        government regulations in whatever country one is in. 
        While the GnuCash "engine" might remain free,
        maintenance of payroll functionality would require
        "subscribing" to an update scheme; it might be troublesome
        to try to provide such a "subscription" free of charge.
        <p></p>
      </dd>

      <dt><a name="invoice"><b>Invoicing</b></a></dt>

      <dd>Invoicing.  Note that invoicing and order entry are 
          closely related.
          Several components:
        <ul>
        <li>Record an invoice. Assign it a serial number.  Be able
            to reprint/report based on invoice serial number.
        <li>Invoice associates customer name to set of transactions.
            Need to deal with PIM issue.  I.e. need to integrate
            with high-function PIM or CRM interface.
        <li>Allow historical browsing of invoices customer by customer.
        <li>To visually design an invoice, need to have a
            mini-word-processor/simple drawing plug-in. Is
            Abisource/Abiword a candidate? Probably needs bonobo...
        </ul>
      </dd>

      <dt><a name="order"><b>Order Entry</b></a></dt>

      <dd>
        Mini-GUI allowing users to type in orders.
        <ul>
        <li>Should interface to parts/inventory database to confirm 
            item availability, (maybe recommend additional production)?
            inventory should be updated after order placement.
        <li>Automatically update accounts receivable.
        <li>Allow order revision/update (esp. as partial orders are shipped).
        <li>Orders can be invoiced when entered (simple invoicing), or
            placed on account (double invoicing).
        <li>Allow back-orders to be printed customer-by-customer, or by 
            product/item.
        <li>Allow printing of packing slip.
        </ul>
        <p></p>
      </dd>

      <dt><a name="estimate"><b>Job Costing</b></a></dt>

      <dd>Ability to prepare and track estimates.
          <ul>
          <li>Allow estimate/bid to be converted to a firm order & get invoiced.
          </ul>
          <p></p>
      </dd>

      <dt><a name="expense"><b>Expense Accounts</b></a></dt>

      <dd>Expense Account Automation, including air, car, hotel,
          dining. Receipts, reservations, cancellations.
          <p></p>
      </dd>
    </dl>

    <h1>References</h1>
    All software and technical standard references have been moved to
    <a href="https://www.gnucash.org/links.php3">
    https://www.gnucash.org/links.php3</a>

    <hr>
    Draft version 0.51 -- June 2001 
    Linas Vepstas 
    <a href="mailto:linas@linas.org">linas@linas.org</a>
    <br>
  </body>
</html>

